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1.  INTRODUCTION 


This  report  describes  the  language  accepted  by  DENOTE  (Denotational  Semantics  Translation 
Environment).  DENOTE  is  a  tool  for  writing  and  implementing  formal  denotational  semantics  t  (Ref.  1)  of 
computer  languages.  DENOTE  provides  a  language,  the  DENOTE  language  (DL),  for  writing 
denotational  semantic  specifications.  DENOTE  can  transform  DL  specifications  into  denotational 
semantic  equations  and  functions  represented  as  plain  ASCII  text  or  as  formatted  text  acceptable  to  the 
Scribe  (Ref.  2)  and  LaTEX  (Ref.  3)  text  formatters.  In  addition,  DENOTE  can  generate  semantic 
implementations,  by  automatically  transforming  DL  specifications  into  Common  Lisp  (Ref.  4)  code  that 
faithfully  implements  the  specified  semantics. 

This  introduction  is  followed  by  four  sections,  an  appendix,  and  an  index.  Section  2  gives  some 
background  on  DENOTE.  Section  3  describes  the  notations  used  in  defining  the  abstract  syntax  of 
programming  languages,  and  presents  some  restrictions  on  the  types  of  abstract  syntax  trees  accepted 
by  DENOTE.  Section  4  describes  the  DENOTE  language  (DL),  in  which  denotational  semantic  equations 
and  functions  are  written.  Section  5  summarizes  the  report.  The  appendix  gives  a  small  example  that 
demonstrates  the  use  of  DENOTE.  The  index  provides  a  cross  reference  to  the  reserved  words  of  DL. 
The  implementation  of  DENOTE,  and  its  user  interface,  are  not  described  in  this  report. 
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familiarity  by  readers  of  this 


report  with  the  concepts  of  denotational  semantics  is  assumed  . 
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ABSTRACT 


The  State  Delta  Verification  System  (SDVS)  is  a  proof  checker  for  correctness  proofs  of  properties 
expressed  in  the  state  delta  logic.  When  one  proves  correctness  properties  of  a  computerc  program 
within  SDVS,  one  must  first  translate  the  program  into  the  language  of  the  state  delta  logic.  The 
translation  semantics  of  a  computer  language  can  be  specified  formally  by  means  of  denotational 
semantics.  In  this  report  we  describe  an  automated  environment  for  specifying  and  implementing 
denotational  semantics,  called  DENOTE  (Denotational  Semantics  Translation  Environment).  The 
language  accepted  by  DENOTE  is  called  the  DENOTE  language  (DL).  DL  is  a  language  in  which  formal 
denotational  semantic  specifications  can  be  written.  DL  specifications  can  be  transformed  by  DENOTE 
into  text  suitable  for  input  to  the  Scribe  and  LaTEX  text  formatters,  as  well  as  into  Common  Lisp  code  that 
implements  the  specified  semantics. 
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The  State  Delta  Verification  System  (SDVS)  is  a  proof  checker  for  correctness  proofs  of  properties  expressed 
in  the  state  delta  logic.  When  one  proves  correctness  properties  of  a  computer  program  within  SDVS,  one 
must  first  translate  the  program  into  the  language  of  the  state  delta  logic.  The  translation  semantics  of  a 
computer  language  can  be  specified  formally  by  means  of  denotational  semantics.  In  this  report  we  describe 
an  automated  environment  for  specifying  and  implementing  denotational  semantics,  called  DENOTE  (Deno¬ 
tational  Semantics  Translation  Environment).  The  language  accepted  by  DENOTE  is  called  the  DENOTE 
language  (DL).  DL  is  a  language  in  which  formal  denotational  semantic  specifications  can  be  written.  DL 
specifications  can  be  transformed  by  DENOTE  into  text  suitable  for  input  to  the  Scribe  and  LaTgX  format¬ 
ters.  as  well  as  into  Common  Lisp  code  that  implements  the  specified  semantics. 
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2.  BACKGROUND 


The  impetus  for  the  design  and  construction  of  the  DENOTE  tool  came  from  certain  requirements 
necessary  for  the  improvement  of  the  State  Delta  Verification  System  (SDVS)  (Ref.  5).  SDVS  is  a  proof 
checker  for  proofs  of  correctness  of  the  properties  of  programs  written  in  various  computer  languages. 
SDVS,  when  checking  such  proofs,  first  translates  the  computer  program  into  SDVS’s  internal  language, 
the  language  of  the  state  delta  logic.  The  correctness  of  this  translation  is  crucial  to  the  proof  process,  in 
that  the  translator  is  directly  responsible  for  specifying  the  semantics  of  the  computer  program  to  be 
translated. 

The  first  computer  language  dealt  with  by  SDVS  was  the  hardware  description  language  ISPS  (Instruction 
Set  Processor  Specification)  (Ref.  6).  ISPS  was  used  to  describe  the  instruction  set  architecture  of  the 
C/30  computer  (Ref.  7)  and  to  describe  the  Microprogrammable  Building  Block  (Ref.  8),  whose  microcode 
was  used  to  emulate  the  C/30  instruction  set.  These  ISPS  descriptions  were  used  in  the  proof  of 
correctness  of  the  C/30  microcode  (Ref.  9),  completed  in  1986.  The  ISPS  translator  used  in  this  proof 
was  implemented  in  an  ad  hoc  manner,  in  that  no  formal  definition  of  the  translation  semantics  was  given. 
Only  through  studying  the  Lisp  code  that  implements  the  translator  could  one  gain  assurance  as  to  the 
correctness  of  the  translator. 

Initiated  in  1988,  an  ongoing  computer  verification  effort  of  the  SDVS  group  is  proving  correctness 
properties  of  programs  written  in  increasingly  complex  subsets  of  Ada*  (Ref.  10).  The  first  of  these 
subsets  was  given  the  name  Core  Ada.  Its  denotational  semantics  was  defined  formally  (Ref.  11)  and  was 
then  implemented  by  handcoding  the  denotational  semantic  equations  and  functions  in  Common  Lisp 
(Ref.  4).  This  task  was  time  consuming,  tedious,  and  almost  automatic  for  the  programmer,  leading  to  the 
realization  that  the  entire  process  could  be  automated.  This  realization  led  to  the  invention  of  DENOTE. 

DENOTE  is  currently  being  used  to  define  state  delta  semantics  for  the  hardware  description  languages 
ISPS  and  VHDL  (Ref.  12),  and  the  programming  language  Ada. 
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3.  ABSTRACT  SYNTAX 


The  denotational  semantics  ot  a  computer  language  is  typically  based  on  an  abstract  syntax  for  the 
language.  The  concrete  syntax  of  a  computer  language  is  the  syntax  used  to  parse  sentences  in  the 
language.  A  parse  tree  based  on  the  concrete  syntax  contains  a  complete  derivation  of  the  parsed 
program,  with  an  internal  node  for  each  concrete  syntax  production  that  is  reduced  during  parsing.  In 
abstracting  the  concrete  syntax,  the  resulting  parse  trees  (abstract  syntax  trees)  become  smaller  and 
more  manageable.  The  differences  between  the  two  syntaxes  are  best  explained  via  an  example. 
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(expr  (sum  (factor  (term  (bnum  (bdigit  1) 

(bnum  (bdigit  0) 

(bnum  (bdigit  1) ) ) ) ) ) 

(addop  +) 

(sum  (factor  (term  (bnum  (bdigit  1) 

(bnum  (bdigit  X)))))))) 

Figure  3-1:  Parse  Tree  for  101+11  using  Concrete  Syntax 

' - - - 


Consider  the  context-free  language  L  generated  by  the  concrete  syntax  productions  listed  bvlow. 
expr  ::=  sum 

sum  :>  factor  addop  sum  |  factor 
factor  term  mulop  factor  |  term 
term  :>  bnum  |  (  expr) 
addop  ::=  + 1  - 
mulop  ::=  *  |  / 

bnum  bdigit  bnum  |  bdigit 

bdigit  0  1 1 

each  sentence  in  this  language  represents  an  arbitrary  arithmetic  term  involving  the  operations  of 
addition,  subtraction,  multiplication,  and  division  applied  to  sequences  of  binary  digits.  The  concrete 
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parse  tree  for  the  sentence  101+11  is  shown  in  Figure  3*1.  The  nonterminal  symbols  of  these  concrete 
syntax  productions  are  expr,  sum,  factor,  term,  addop,  mulop,  bnum,  and  bdigit;  the  terminal  symbols  are 
(. ),  +.  *.  /.  0,  and  1.  The  notations  :>  and  |  represent  derivation  and  alternation,  respectively.  Note  that 
no  pseudoterminals^  are  used  to  define  L,  (either  bnum  or  bdigit  could  be  pseudoterminals). 


plus 

A 

bdlgits  bdlglts 
I  I 

(1  0  1)  (1  1) 

(plus  (bdlgits  (1  0  1))  (bdlgits  (1  1))) 

Figure  3-2:  Parse  Tree  for  101+11  using  Abstract  Syntax 

\ . . . . . . J 

Productions  defining  an  abstract  syntax  for  L  are  shown  below, 
expr  binary-op  expr1  expr2  |  BDIGITS  bdigit+ 

binary-op  PLUS  |  MINUS  i  MULT  |  DIVIDE 

bdigit  ::=  0  1 1 

In  the  abstract  syntax,  expressions  are  generalized  (operator  precedence  explicit  in  the  concrete  syntax 
no  longer  requires  representation)  and  production  sequences  are  compressed.  The  abstract  parse  tree 
for  the  sentence  101+11  is  shown  in  Figure  3-2.  The  nonterminal  symbols  of  the  abstract  syntax 
productions  are  expr,  binary-op,  and  bdigit;  the  terminal  symbols  are  BDIGITS,  PLUS,  MINUS,  MULT, 
DIVIDE,  0,  and  1. 


3.1 .  A  Language  for  Abstract  Syntax 

Before  formally  defining  the  language  for  representing  abstract  syntax  productions,  some  notation  must 
be  introduced.  Itemized  below  are  language  notations  for  terminal  symbols,  sequences  of  (arbitrary) 
symbols,  the  empty  sequence,  and  a  syntactic  method  for  disambiguating  multiple  occurrences  of 
symbols  in  a  production. 

•  '  x  denotes  a  terminal  symbol  x. 

•  (x  +)  denotes  a  sequence  of  one  or  more  x. 

•  (x  *)  denotes  a  sequence  of  zero  or  more  x. 

•  epsilon  denotes  the  empty  derivation. 

•  (x  n) ,  where  n  is  a  symbol  (typically  a  natural  number),  may  be  used  to  disambiguate 
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pseudo  terminal  denotes  a  class  ol  terminal  symbols,  such  as  ■identifiers"  or  "numerals.” 
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multiple  occurrences  of  the  (nonterminal  or  pseudoterminal)  symbol  x  in  an  individual 
production.  The  symbol  n  qualifies  x,  by  distinguishing  it  from  other  occurrences  of  x  in  the 
production,  in  a  like  manner,  (x  *  n)  may  be  used  to  qualify  an  occurrence  of  (x  *)  and 
(x  +  n)  to  qualify  an  occurrence  of  (x  +) .  DENOTE  requires  qualification  in  a  production 
when  more  than  one  occurrence  of  a  nonterminal  or  pseudoterminal  symbol  appears  .in  the 
production. 

For  example,  consider  a  syntactic  phrase^  of  L,  derived  from  the  nonterminal  expr,  shown  below: 

PLUS  expr,  expr2 

The  DENOTE  language  (DL)  notation  for  this  phrase  is 

('PLUS  (expr  1)  (expr  2)) 

Without  the  qualification  of  expr,  DENOTE  would  have  no  natural  way  of  distinguishing  between  the  two 

when  referencing  them  from  within  a  semantic  equation. 

The  formal  definition  of  the  DENOTE  language  for  representing  abstract  syntax  is  given  below. 

•  An  abstract  syntax  is  a  list  of  productions. 

•  A  production  is  a  list  whose  first  element  is  a  nonterminal  and  whose  remaining  elements  are 
the  alternatives  generated  by  (derived  from)  the  nonterminal.  The  symbol  epsilon  denotes 
the  empty  derivation.  Each  list  representing  a  production  must  have  at  least  two  elements, 
the  simplest  production  being  (nt  epsilon) ,  denoting  a  nonterminal  nt  that  has  only  the 
empty  derivation.  If  the  nonterminal  defining  the  production  also  appears  within  one  of  the 
alternatives,  duplicate  occurrences  of  the  nonterminal  must  be  qualified  for  disambiguation. 

•  An  alternative  is  either  a  terminal  symbol,  a  nonterminal  symbol  (or  sequence  thereof),  a 
pseudoterminal  symbol  (or  sequence  thereof),  or  a  list  of  the  aforementioned  symbols. 

A  DL  representation  of  the  abstract  syntax  for  the  example  language  L  is  shown  below. 

((expr  (binary-op  (expr  1)  (expr  2)) 

('bdigits  (bdigit  +) ) ) 

(binary-op  ' plus  '  minus  '  mult  ' divide) 

(bdigit  '0  '1)) 

If  bdigit  was  defined  to  be  a  pseudoterminal  of  L,  the  final  production  would  be  absent. 


3.2.  Implementation  Requirements  for  Abstract  Syntax  Trees 

DENOTE  requires  a  particular  physical  representation  of  abstract  syntax  trees.  These  trees  must 
conform  to  the  following  rules: 

•  An  abstract  syntax  tree  contains  no  nonterminal  symbols,  only  terminal  and  pseudoterminal 
symbols  and  lists  thereof.  DENOTE  is  case-insensitive. 

•  Terminal  symbols  appear  verbatim. 

•  A  pseudoterminal  is  represented  by  the  appearance  of  the  particular  symbol  parsed. 

•  A  sequence  of  symbols  (defined  by  either  the  +  or  *  notation)  is  epresented  by  a  list 
containing  each  symbol’s  representation,  or  by  the  empty  list  if  the  sequence  is  empty. 


tay 


"syntactic  phrase"  we  mean  some  derivation  ot  a  nonterminal  from  the  abstract  syntax. 
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•  An  alternative  that  is  defined  in  the  abstract  syntax  by  a  list  of  symbols  must  be  represented 
by  a  list  that  contains  the  ordered  representation  of  each  symbol,  the  first  symbol  of  which 
must  be  a  unique  terminal  symbol.  This  requirement  permits  DENOTE  to  disambiguate 
different  syntactic  phrases  derived  from  a  single  nonterminal. 

A  few  examples  of  abstract  syntax  trees  for  L  should  clarify  these  implementation  requirements.  The 
terminal  symbol  PLUS  is  represented  by  the  atom  plus.  The  binary  digit  0  is  represented  by  the  atom  o. 
The  binary  number  101  is  represented  by  the  list  (bdigits  (l  o  l) ) .  The  syntactic  phrase  1001+11 
is  represented  by  the  list  (plus  (bdigits  (10  0  1))  (bdigits  (1  1))). 
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4.  DENOTE  LANGUAGE  (DL) 


This  section  describes  in  detail  the  syntax  of  the  DENOTE  language  (DL)  for  defining  denotational 
semantic  equations  and  auxiliary  functions.  This  preliminary  version  of  DL  is  syntactically  similar  to  Lisp 
(Ref.  13),  consisting  of  atomic  terms  and  s-expressions  (parenthesized  lists).  The  following  groups  of 
language  constructs  are  defined: 

•  the  atomic  terms  (constants  and  variables) 

•  the  built-in  operators  and  functions 

•  a  construct  for  defining  denotational  semantic  equations  (defsemaq),  and  additional 
constructs  for  specifying  the  syntactic  arguments  of  semantic  functions  (synciause)  and  for 
preventing  the  currying  of  arguments  (args) 

•  a  construct  for  defining  auxiliary  functions  (defsemfn) 

•  the  control  structure  constructs  if,  alseif ,  and  notations  for  applying  semantic  functions, 
auxiliary  functions,  and  continuations  (appiycont)  to  arguments 

•  the  binding  constructs  let,  where,  whererec,  and  lambda 

•  the  grouping  constructs  1st,  tuple,  and  synciause  for  binding  new  variables 
A  full  list  of  the  reserved  words  of  DL  is  shown  in  the  index  at  the  back  of  this  report. 

In  the  sections  to  follow,  tables  are  used  to  show  groups  of  syntactic  objects.  Each  table  has  three 
columns,  labeled  Denotations,  DL,  and  Common  Lisp,  respectively.  The  middle  column  shows  the  DL 
syntax  of  a  reserved  word  or  construct.  The  first  column  shows  its  denotational  representation  as 
displayed  by  the  Scribe  text  formatter.  The  third  column  shows  the  fragment  of  Common  Lisp  code  that 
implements  the  object.  The  reserved  words  of  DL  are  displayed  in  a  bold,  fixed-width  font,  as  are  all 
Common  Lisp  constructs.  DL  is  case-insensitive. 


4.1 .  Atomic  Terms 

Constants  and  variables  comprise  the  atomic  terms  of  DL. 

4.1.1.  Constants 

Table  4-1  shows  the  syntax  for  the  constants  of  DL.  These  constants  include  the  empty  derivation 
epsilon,  the  empty  set  emptyset,  the  Booleans  tt  and  f  f ,  the  numerals,  atomic  identifier  constants, 
and  strings. 

4.1.2.  Variables 

Table  4-2  shows  the  syntax  for  variables  of  DL.  All  identifiers  that  are  not  reserved  words  of  DL  can  be 
used  as  variables,  except  for  t,  which  for  historical  reasons  is  reserved  to  denote  a  variable  named  TSE.^ 


*TSE 


is  an  acronym  for  Tree  Structured  Environment. 
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r 


\ 


Denotation 

DL 

Common  Usd 

e 

epailon 

nil 

0 

emptyset 

nil 

tt 

tt 

t 

ff 

ff 

nil 

...,-1,0,1,... 

•  •  •  t  “1  /  0,1/  .  .  . 

• . . / —l/ 0 / 1 / . • . 

bold-ld 

'bold-id 

' bold-id 

bold-ld 

(quote  bold-id) 

'bold- id 

bold-ld 

(bold  bold-id) 

'bold- id 

BOLD-ID 

(ubold  bold-id) 

' bold- id 

"xxxxx" 

(atring  "xxxxx") 

"xxxxx” 

\ 

Table  4-1 :  Constants  of  DL 

/ - 

Denotation 

DL 

Common  Lisp 

t 

t 

tae 

identifier 

identifier 

identifier 

xi 

(acriptarg  (x  1} ) 

xl 

x+ 

(acriptarg  (x  +) ) 

x+ 

X* 

(acriptarg  (x  *)) 

X* 

x+2 

(acriptarg  (x  +  2) ) 

x+2 

X*3 

(acriptarg  (x  *  3) ) 

x*3 

[[s4)) 

(aynarg  (a  4)) 

a4 

Hs*]] 

(aynarg  (a  *)) 

a* 

[[S+]) 

(aynarg  (a  +)) 

a+ 

l[s*5]l 

(aynarg  (a  *  5)) 

a*5 

l[s*6]] 

(aynarg  (a  +  6) ) 

8+6 

[[s]] 

(aynarg  a) 

a 

KID]] 

(aynarg  '  id) 

'  id 

KID]] 

(aynarg  (quote  id) ) 

'id 

\ _ 

Table  4-2:  Variables  of  DL 

/ 

\ 


J 


In  addition,  DL  has  two  notations  for  introducing  subscripted  variable  names  into  denotational  semantic 
descriptions.  These  notations  are  headed  by  the  identifiers  acriptarg  and  aynarg.  The  acriptarg 
notation  can  be  applied  to  any  variable,  whereas  only  syntactic  variables  can  be  contained  within 
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synarg.  When  a  semantic  function  is  applied  to  arguments  (the  first  of  which  must  be  syntactic),  the  first 
argument  must  be  enclosed  in  the  synarg  form,  to  distinguish  it  from  the  remainder  of  the  (nonsyntactic) 
arguments.^  This  first  argument  may  be  the  empty  sequence  epsilon,  a  (quoted)  terminal  symbol,  a 
pseudo-terminal  symbol  (or  sequence  thereof),  or  a  nonterminal  symbol  (or  sequence  thereof). 

/ - - - - - v 


Denotation 

DL 

-i  X 

(not  x) 

x  v  y 

(or  x  y) 

x  a  y 

(and  x  y) 

x  =  y 

(eq  x  y) 

(=  x  y) 

x  *  y 

(neq  x  y) 

<~=  x  y) 

x  <  y 

(It  x  y) 

(<  x  y) 

x  <  y 

(le  x  y) 

(<=  x  y) 

x  >  y 

(gt  x  y) 

(>  x  y) 

x  5  y 

(ge  x  y) 

(>=  x  y) 

-  X 

(minus  x) 

(-  x) 

x  +  y 

(plus  x  y) 

(+  x  y) 

x  -  y 

(minus  x  y) 

(-  x  y) 

x  *  y 

(mult  x  y) 

<*  x  y) 

x/  y 

(divide  x  y) 

(/  x  y) 

x  A  y 

(expt  x  y) 

(A  x  y) 

x  e  y 

(member  x  y) 

xuy 

(union  x  y) 

xny 

(intersection 

x  y) 

Table  4-3:  Built-in 


Common  Lisp 

(not  x) 

(or  x  y) 

(and  x  y) 

(equal  x  y) 

(not  (equal  x  y) ) 

«  x  y) 

<<=  x  y) 

(>  x  y) 

(>=  x  y) 

(-  x) 

(+  x  y) 

(-  x  y) 

(*  x  y) 

(quotient  x  y) 

(expt  x  y) 

(member  x  y  :test  'equal) 

(union  x  y  :test  'equal) 
(intersection  x  y  :test  'equal) 

ix  Operators  of  DL 

_ / 


4.2.  Built-in  Infix  Operators  and  Built-in  Functions 

Table  4-3  shows  the  syntax  for  the  built-in  operators  of  DL  that  have  infix  denotations.  The  built-in 
operators  consist  of  the  Boolean  relations  negation  (not),  conjunction  (or),  and  disjunction  (and);  the 
logical  relations  equality  (eq,=)  and  disequality  (neq,~=);  the  integer  inequalities  less  than  (it,<),  less 
than  or  equal  (le,<=),  greater  than  (gt,>),  and  greater  than  or  equal  (ge,>=);  the  integer  operators  unary 
negation  (minus,-),  addition  (pius,[+]),  subtraction  (minus,-),  multiplication  (mult,*),  division 
(divide,/),  and  exponentiation  (expt,'');  and  the  set  operators  membership  (member),  union  (union), 
and  intersection  (intersection). 

Table  4-4  shows  the  syntax  for  the  built-in  functions  of  DL,  i.e.,  those  built-in  operators  that  have  no  infix 
denotations.  These  built-in  functions  are  list  head  (hd),  list  tail  (ti),  list  length  (length),  dotted-list 
construction  (cons),  list  type  identification  (consp),  list  append  (append),  conventional  list  construction 
(list),  identifier  concatenation  (catenate),  integer  maximum  (max),  integer  minimum  (min),  integer 


+A 


syntactic  argument  s  is 


distinguished  by  the  denotation  |[sj). 
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remainder  (ram),  integer  modulus  (mod),  and  integer  absolute  value  (abs).  Adding  new  built-in  operators 
and  functions  to  DL,  as  the  need  arises,  is  not  difficult. 

/ - - - - - \ 


Denotation 

DL 

Common  Lisp 

hd(x) 

(hd  x) 

(car  x) 

tl(x) 

<tl  X) 

(edr  x) 

length(x) 

(length  x) 

(length  x) 

cons(x.y) 

(cona  x  y) 

(cons  x  y) 

consp(x) 

(consp  x) 

(consp  x) 

append(x.y) 

(append  x  y) 

(list  x  y) 

lisUx^Xg,...) 

(list  xx  x2  .  .  . ) 

(list  xl  x2 

catenate(x.y) 

(catenate  x  y) 

(pack*  x  y) 

max(x,y) 

(max  x  y) 

(max  x  y) 

min(x.y) 

(min  x  y) 

(min  x  y) 

rem(x.y) 

(rem  x  y) 

(rem  x  y) 

mod(x.y) 

(mod  x  y) 

(mod  x  y) 

abs(x) 

(abs  x) 

(abs  x) 

Table  4-4:  Built-in  Functions  of  DL 


\ _ —I 


4.3.  Semantic  Equations 

The  DL  expression  that  defines  a  single  denotational  semantic  equation  is  a  six-element  list  headed  by 
the  identifier  defaeraaq,  whose  remaining  five  fields  contain  the  following: 

2.  the  atomic  name  of  the  semantic  function, 

3.  a  unique  atomic  label  for  the  semantic  equation, 

4.  the  syntactic  argument  of  the  equation, 

5.  a  list  of  the  arguments  to  the  function,  and 

6.  the  body  of  the  equation. 

For  example,  consider  the  following  de£semeq  form: 

(def  aeirveq 

E  E4  (aynclause  expr  ('divide  (expr  1)  (expr  2)))  (c) 

(where  ( ( (acriptarg  (c  1) ) 

(lambda  (x) 

(where  (((acriptarg  (c  2)) 

(lambda  (y) 

(if  (=  x  0) 

(division-error) 

(applycont  c  (/  y  x) ) ) ) ) ) 

(E  (synarg  (expr  1) )  (acriptarg  (c  2 ))))))) 

(E  (synarg  (expr  2))  (acriptarg  (c  1))))) 

This  form  defines  a  semantic  function  named  E  and  labeled  E4,  with  the  syntactic  argument 
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[[DIVIDE  expr,  expr2]],  the  semantic  arguments  (c),  and  a  body  that  is  best  explained  by  the  remainder  of 
this  report.  The  interior  constituents  of  the  defaemaq  form  are  the  topic  of  the  remainder  of  this  section. 
Semantic  equation  E4  is  also  presented  in  the  Appendix. 

4.3.1.  Names  and  Labels 

Each  semantic  equation  defined  via  def semeq  first  identifies  the  name  of  the  semantic  function  for  which 
an  instance  is  being  defined.  Since  each  semantic  function  operates  on  one  or  more  syntactic  domains, 
several  semantic  equations  may  be  required  to  define  the  actions  of  a  particular  semantic  function  on 
different  syntactic  phrases.  Thus,  DENOTE  requires  that  a  unique  (atomic)  label  be  associated  with  each 
equation.  These  labels  may  be  used  to  refer  to  semantic  equations  in  documents  and  are  used  to 
construct  names  for  Common  Lisp  functions  that  implement  the  semantic  equations.  A  typical 
methodology  for  constructing  label  names  would  be  to  append  consecutive  numerals  to  semantic  function 
names.  For  example,  the  labels  El,  E2,  E3,  and  E4  are  used  to  identify  uniquely  the  four  semantic 
equations  for  the  semantic  function  E  of  the  example  language  L  (described  in  the  Appendix). 

4.3.2.  Syntactic  Arguments 

Each  semantic  equation  defined  via  defsemeq  specifies  the  actions  of  a  semantic  function  on  a  particular 
syntactic  phrase.  DENOTE  requires  that  the  syntactic  argument  to  each  semantic  equation  be 
represented  by  a  syntactic  clause,  which  contains  both  a  syntactic  phrase  and  the  Nonterminal  or 
pseudoterminal  from  which  the  phrase  was  derived.  The  DL  expression  defining  a  semantic  clause  is  a 
three-element  list  headed  by  the  identifier  aynciause,  whose  remaining  two  fields  contain,  respectively, 
a  nonterminal  or  pseudoterminal  symbol  (or  sequence  thereof)  for  one  of  the  syntactic  phrases  it  derives. 
The  syntax  of  both  arguments  to  aynciause  must  conform  to  that  imposed  on  symbols  and  alternatives 
in  abstract  syntax  productions. 

For  example,  consider  the  following  syntactic  clause  taken  from  the  original  dafaemeq  example: 
(aynciause  expr  ('DIVIDE  (expr  1)  (expr  2))) 

This  !c  the  syntactic  clause  that  represents  a  binary  expression  involving  division,  derived  from  the 
following  two  productions  in  the  abstract  syntax  for  L. 
expr  ::=  binary-op  expr,  expr2 

binary-op  ::=  PLUS  |  MINUS  |  MULT  |  DIVIDE 

Below  are  some  examples  of  syntactic  clauses  involving  sequences  of  the  nonterminal  bdigit.  To  the 
right  of  each  clause  is  the  embedded  phrase  as  it  would  appear  as  the  syntactic  argument  in  a  semantic 
equation. 

(aynciause  (bdigit  *  1)  (bdigit  (bdigit  *  2)))  [[bdigit  bdigit*2]] 

(aynciause  (bdigit  *)  epsilon))  [[e]] 

(aynciause  (bdigit  *)  (bdigit  *))  [[bdigit*]] 


13 


(synclausa  (bdigit  +)  (bdigit  +) )  [[bdigit*]] 

(synclausa  (bdigit  +  0)  ((bdigit  *)  bdigit))  [[bdigit*  bdigit]] 

All  of  the  above  examples  conform  to  the  DL  syntax,  and  are  appropriately  qualified.  Note  that 
qualification  is  unnecessary  if  the  alternative  (the  second  argument  to  synclausa)  is  identical  to  the  first 
argument,  as  shown  in  the  third  and  fourth  examples  above. 

4.3.3.  Semantic  Arguments 

The  semantic  arguments  of  each  semantic  equation  are  represented  by  a  list  of  identifiers;  each  identifier 
in  the  list  represents  a  single  argument  to  the  function.  Note  that  since  currying  is  the  default  in 
denotations  semantics,  we  need  additional  notation  for  grouping  arguments.  The  notation 
(args  a  b  c  . . . ) 

groups  a  set  of  arguments  together,  that  is,  it  uncurries  them.  For  example,  the  DL  notation 
(a  (args  be)  d  a)  denotes  the  following  argument  list;  (a)(b,c)(d)(e).  If  the  args  notation  is  used 
to  define  the  arguments  to  a  function,  the  notation  must  be  used  correspondingly  when  the  function  is 
applied  to  arguments. 

4.4.  Auxiliary  Functions 

Before  describing  the  DL  constituents  of  the  bodies  of  equations  and  functions,  we  must  describe  a  form 
used  to  define  auxiliary  functions  that  may  be  used  by  semantic  equations.  The  DL  expression  defining 
an  auxiliary  function  is  a  four-element  list  headed  by  the  atom  def  semfn,  whose  remaining  three  fields 
contain  the  following: 

2.  the  atomic  name  of  the  function, 

3.  a  list  of  the  names  of  the  function's  parameters  (which  may  be  grouped  using  args),  and 

4.  the  body  of  the  function. 

For  example,  the  factorial  function  for  non-negative  integers  is  defined  in  DL  as  follows: 

(dafsamfn  factorial  (n) 

(if  (=  n  0) 

1 

(*  n  (factorial  (-  n  1))))) 

4.5.  Equation  and  Function  Bodies 

The  bodies  of  semantic  equations  and  auxiliary  semantic  functions,  of  course,  comprise  the  majority  of 
DL.  These  bodies  consist  of  terms,  some  of  which  are  special  denotations. 
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Denotation 

DL 

Common  Lisp 

(P  ->  a,  b) 

(if  p  •  b) 

(if  P 

a  b) 

(P-*  a, 

(elseif  p  a 

(cond 

(P  a) 

q  -» b, 

q  b 

(q  b) 

c) 

c) 

(t  c)) 

SF[(s]](x)(y)... 

(SF  (synarg  s)  x  y  ...) 

(SF  s 

x  y  .  .  .  ) 

f(xi)(x2)... 

(f  xl  x2  .  .  .) 

(f  xl 

x2  .  .  .) 

f(x,  .X2,-.-) 

(f  (args  xl  x2  . . . ) ) 

(£  xl 

x2  .  .  .  ) 

f(x1)(x2)(x3,x4,...) 

(f  xl  x2  (args  x3  x4  . . . ) ) 

(£  xl 

x2  x3  x4  . . . ) 

k(a)(b)(c) 

(applycont  k  a  b  c) 

(apply-cont  k  (list 

a  b  c) ) 

k(a,b,c) 

(applycont  k  (args  a  b  c) ) 

(apply-cont  k  (list 

a  b  c)) 

Tabid  4-5:  Control  Structures  in  DL 


\ _ _ _ / 

Control  Structures 

Table  4-5  shows  the  DL  syntax  for  the  control  structures  used  in  the  bodies  of  denotational  equations  and 
functions.  The  forms  described  are  the  two  conditionals  if  and  elseif ,  the  form  for  semantic  function 
application  (note  that  the  first  argument  to  a  semantic  function  must  be  a  syntactic  argument,  enclosed  by 
the  synarg  construct,  as  discussed  previously),  the  form  for  general  function  application,  and  the  form  for 
applying  continuation  variables  to  arguments  (applycont). 

Grouping  Constructs 

Table  4-6  show  the  syntax  of  DL’s  constructs  for  binding  variables  and  functions,  including  the  where  and 
let  constructs  for  binding  variables  in  various  manners,  the  whererec  form  for  locally  binding  a  name  to 
a  recursive  function,  and  the  lambda  forms  for  function  definition.  The  let  and  where  forms  permit  four 
distinct  types  of  bindings:  (1)  binding  of  a  variable  to  the  empty  sequence  (the  empty  list),  (2)  binding  of  a 
variable  to  the  value  of  an  expression,  (3)  binding  of  sequences  (lists  and  tuples)  of  variables  to  elements 
of  lists,  and  (4)  binding  of  syntactic  variables  in  the  syntactic  phrase  of  a  syntactic  clause  to  a  list  of 
syntactic  values. 

Grouping  Operators 

Table  4-7  shows  the  three  grouping  operators  for  the  let  and  where  control  structures,  which  display  as 
parenthesized  lists,  and  angle-bracketed  lists  (tuples).  Note  that  the  identifier  let  is  used  instead  of 
Hat  for  denotations  of  the  form  (x^Xg,...).  This  is  because  list  is  reserved  for  denotations  of  the  form 
list(x1,x2,...),  which  represents  the  list  constructor  operator  as  applied  to  arguments. 


r 
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Denotation 

DL 

Common  LiSD 

let  X  a  E  ... 

(let  (x>  ...) 

(let  (x)  . . . ) 

let  x  =■  y ... 

(let  ( (x  y) )  .  .  . ) 

(let  ( (x  y) )  . .  . ) 

let  (xl . xk)  »  y  ... 

(let  ( ( (1st  xl  ...  xk)  y) )  .  .  . ) 

(let<k>  ( (xl  .  .  .  xk) 

y)  ...) 

let  <x1,...,xk>  =  y  .. 

(let  (((tuple  xl  ...  xk)  y) ) . . . ) 

(let<k>  ( (xl  . . .  xk) 

y)  ...) 

let  [(xl . xk]]  *  y  .. 

.  (let  ( ( (synclause  s  (si  . . .  sk) ) 
e))  ...) 

(let<k>  ( (si  ...  sk) 
...) 

y) 

...  where  x  »e 

(where  (x)  .  . . ) 

(let  (x)  ...) 

...  where  x  *  y 

(where  ( (x  y) )  .  .  . ) 

(let  ( (x  y) )  .  .  . ) 

and  so  on.  The  remaining  where  denotations  follow  the  pattern  of  the  let  denotations: 

...  whererec 
f(a)(b)...=exp 

(whererec 

( (£  (lambda  (a  b  ...)  exp))) 

...) 

(labels 

( (£  (a  b  . . . )  exp) ) 

.  •  .) 

Xx.Xy.Xz...body 

(lambda  (x  y  z  . . . ) 
body) 

(function 

(lambda  (x  y  z  . . . ) 

body) ) 

X(x,y,z,...).  body 

(lambda  ( (args  x  y  z  . . . ) ) 
body) 

(function 

(lambda  (x  y  z  .  .  . ) 

body) ) 

\ _ 

Table  4-6 :  Binding  Constructs  of  DL 

/ 

Denotation  DL 


Common  Lisp 


X  -  E 

x-y 

(x1,x2,...)  -  y 
<x1,x2,...>  =  y 
[[Sl,s2,...]]-y 


(x  y  .  .  . ) 

( (u  v)  (w  x) ) 

( ( (1st  xl  x2  .  .  . )  y) } 

( ( (tuple  xl  x2  . . . )  y) ) 

( ( (synclause  s  (si  s2  . . . ) ) 


bind  x  to  NIL,  y  to  NIL, ... 
bind  u  to  the  value  of  v,  w  to  x,  etc. 
binds  each  xn  to  the  nth  element  of  y 
binds  each  xn  to  the  nth  element  of  y 
binds  each  sn  to  the  nth  element  of  y 


y>> 


N. 


Table  4-7:  The  Syntax  of  Bindings  Within  let  and  where 


J 
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5.  SUMMARY 


The  design  and  implementation  of  the  DENOTE  tool  was  necessitated  by  the  Computer  Verification 
Group's  problems  with  ad  hoc  implementations  of  translators  for  computer  languages  dealt  with  by  SDVS. 
DENOTE  now  permits  users  to  specify  the  formal  denotational  semantics  of  a  computer  language  in  its 
internal  language  DL,  and  is  capable  of  automatically  transforming  a  DL  specification  into  text  that  may  be 
examined  for  semantic  correctness,  as  well  as  into  a  Common  Lisp  implementation  of  the  specified 
semantics.  DENOTE  is  currently  used  to  define  the  translation  semantics  of  Ada,  VHDL,  and  ISPS,  which 
permits  SDVS  to  translate  computer  language  constructs  into  the  internal  language  of  SDVS.  DENOTE  is 
not,  however,  restricted  to  defining  SDVS  translation  semantics.  It  is  a  general-purpose  tool  for  displaying 
and  implementing  the  denotational  semantics  of  computer  languages. 

The  current  implementation  of  DENOTE  has  been  found  to  be  adequate  to  the  tasks  presented  to  it,  but 
has  room  for  improvement.  Some  improvements  that  would  extend  its  applicability  and  usability  include 
the  following: 

•  Improving  the  checking  capabilities  of  DENOTE  with  respect  to  static  semantics,  e.g.  type- 
check  variables  and  function  parameters,  check  that  function  calls  have  the  required  number 
of  arguments. 

•  Implementing  a  friendlier  user  interface  to  DENOTE,  and  providing  good  documentation  for 
the  interface  (no  such  documentation  is  provided  by  this  report).  This  interface  should  include 
a  facility  for  processing  an  individual  semantic  equation  or  auxiliary  function,  whereas  the 
current  version  of  DENOTE  requires  the  processing  of  the  entire  denotational  semantic 
definition. 

•  Incorporating  additional  denotational  constructs  into  DL,  and  modifing  the  syntax  of  DL  to 
clear  up  confusions  or  ambiguities. 

•  Providing  an  optimizer  for  the  automatically  generated  Common  Lisp  code. 

•  Improving  the  formatting  capabilities  of  DENOTE  with  respect  to  the  Scribe  and  LaTEX  text 
formatters. 

A  report  describing  DENOTE  in  full,  including  its  user  interface,  will  be  forthcoming. 
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APPENDIX 
THE  LANGUAGE  L 


A  denotational  semantics  for  the  example  language  L  (introduced  in  Section  3)  is  presented  in  this 
appendix.  First  the  concrete  and  abstract  syntaxes  are  given  for  L.  Next  the  semantics  for  L  is 
described  informally,  followed  by  its  formal  semantics  written  in  DL.  Two  outputs  produced  by  DENOTE, 
the  text-formatted  version  of  the  semantics  of  L  and  its  Common  Lisp  implementation,  are  then 
presented.  Finally,  some  examples  of  using  the  Common  Lisp  implementation  to  determine  the 
semantics  of  sentences  in  Lare  shown. 


1 .  Concrete  Syntax  for  L 

The  concrete  syntax  of  L  is  shown  below.  As  mentioned  previously,  each  sentence  in  L  represents  an 
arbitrary  arithmetic  term  involving  the  operations  of  addition,  subtraction,  multiplication,  and  division 
applied  to  sequences  of  binary  digits. 


expr 

=  sum 

sum 

=  factor  addop  sum  |  factor 

factor 

=  term  mulop  factor  |  term 

term 

-  bnum  |  ( expr ) 

addop 

=  +  |- 

mulop 

-*l  / 

bnum 

=  bdigit  bnum  |  bdigit 

bdigit 

—  0)1 

2.  Abstract  Syntax  for  L 

The  abstract  syntax  of  L  is  shown  below.  The  abstract  syntax  productions  generate  the  same  language 
that  concrete  syntax  does,  while  eliminating  extraneous  productions  related  to  parsing,  and  thus  is 
considerably  more  compact. 

expr binary-op  expr,  expr2 1  BDIGITS  bdigit+ 
binary-op  :>  PLUS  |  MINUS  |  MULT  |  DIVIDE 
bdigit  0  1 1 

Shown  below  is  the  Common  Lisp  syntax  for  binding  the  variable  *binexpr-abatract-ayntax*  to  the 
DL  abstract  syntax  of  L.  The  abstract  syntax  representation  is  case-insensitive.  We  a  follow  a 
convention  when  displaying  abstract  syntax  productions  of  presenting  terminal  symbols  in  upper  case, 
and  all  other  symbols  in  lower  case. 

(dafvar  *binexpr-abatract-ayntax* 

( (expr  (binary-op  (expr  1)  (expr  2)) 

('bdigit a  (bdigit  +) ) ) 

(binary-op  'plua  'minua  'mult  'divide) 

(bdigit  '0  '1))) 
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3.  Informal  Semantics  for  L 


Informally,  we  choose  a  semantics  for  L  that  assigns  integers  to  sentences  in  L,  except  for  those  that 
involve  division  by  zero,  to  which  we  assign  an  error  string.  In  this  semantics,  sequences  of  binary  digits 
represent  non-negative  binary  numbers. 


4.  Formal  Semantics  for  £  in  DL 

The  DL  representation  of  the  formal  semantics  for  L  is  shown  below.  This  is  a  continuation-style 
denotational  semantics  that  maps  illegal  expressions  (those  involving  division  by  0)  into  an  error  string 
and  legal  expressions  to  their  integer  results.  The  values  of  three  variables  are  defined.  The  variable 
*binexpr-sem£ns*  is  bound  to  an  association  list  of  semantic  function  names,  where  the  tail  of  each 
sublist  contains  the  syntactic  domains  (specified  by  the  nonterminals  of  the  abstract  syntax)  to  which  the 
semantic  function  may  be  applied.  The  variable  *binexpr-fns*  is  bound  to  an  association  list  of  the 
auxiliary  functions.  Finally,  the  variable  *binexpr-semantics*  is  bound  to  the  DL  semantics  for  L. 

(defvar  *binexpr-semfns* 

' ( (A  expr) 

(B  expr) 

(E  (bdigit  *)))) 

(defvar  *binexpr-£ns* 

' ( (division-error) ) ) 

(defvar  *binexpr-semantics* 

' ( (def semeq 

A  A1  (synclause  expr  expr)  () 

(E  (synarg  (expr) )  (lambda  (x)  x) ) ) 

(defsemeq 

E  El  (synclause  expr  ('plus  (expr  1)  (expr  2)))  (c) 

(E  (synarg  (expr  1) ) 

(lambda  (x)  (E  (synarg  (expr  2))  (lambda  (y)  (applycont  c  (+  x  y) ) ) ) ) ) ) 
(defsemeq 

E  E2  (synclause  expr  ('minus  (expr  1)  (expr  2)))  (c) 

(let  (((scriptarg  (c  1)) 

(lambda  (x) 

(E  (synarg  (expr  2))  (lambda  (y)  (applycont  c  (-  x  y) ) ) ) ) ) ) 

(E  (synarg  (expr  1))  (scriptarg  (c  1))))) 

(defsemeq 

E  E3  (synclause  expr  ('mult  (expr  1)  (expr  2)))  (c) 

(where  ( ( (scriptarg  (c  1) ) 

(lambda  (x)  (E  (synarg  (expr  2)) 

(lambda  (y)  (applycont  c  (*  x  y) ) ) ) ) ) ) 

(E  (synarg  (expr  1))  (scriptarg  (c  1))))) 
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(defaemeq 

E  E4  (synclause  expr  ('divide  (expr  1)  (expr  2)))  (c) 

(where  ( ( (acriptarg  (c  1) ) 

(lambda  (x) 

(where  (((acriptarg  (c  2)) 

(lambda  (y) 

(if  (=  x  0) 

(diviaion-error) 

(applycont  c  (/  y  x) ) ) ) ) ) 

(E  (aynarg  (expr  1) )  (acriptarg  (c  2) ) ) ) ) ) ) 
(E  (aynarg  (expr  2))  (acriptarg  (c  1))))) 


(defaemfn  diviaion-error  ()  (atring  "division  by  zero")) 
(defaemeq 

E  E5  (synclause  expr  ('bdigits  (bdigit  +) ) )  (c) 
(applycont  c  (B  (aynarg  (bdigit  +) )  0) ) ) 

(defaemeq 

B  B1  (synclause  (bdigit  *  0)  (bdigit  (bdigit  *)))  (n) 
(B  (aynarg  (bdigit  *))  (+  (*  n  2)  bdigit))) 

(defaemeq 

B  B2  (synclause  (bdigit  *  0)  epsilon)  (n) 
n)) 


The  DL  semantics  for  L  is  explained  in  the  next  section,  where  the  text-formatted  version  of  the  equations 
are  displayed. 


5.  Scribe  Formatted  Denotational  Semantics  for  L 

The  Scribe-formatted  text  displaying  the  abstract  syntax,  semantic  equations,  and  auxiliary  functions 
defining  the  denotational  semantics  for  L  are  show  below.  This  text  was  automatically  generated  by 
DENOTE  from  the  semantic  definition  of  I, written  in  DL. 

expr binary-op  expr,  expr2  |  BDIGITS  bdigit+ 
binary-op  PLUS  |  MINUS  |  MULT  |  DIVIDE 

bdigit  ::=  0  1 1 


(A1)  A  [[exprj  =  Eiexpru(Xx.x) 

(El)  E iPLUS  expr,  expr2i(c)  =  E([expr,i](kx.E[[expr2ii()vy.c(x+y))) 

(E2)  E[  MINUS  expr,  expr2i  (c) 

=  letc,  =  Xx.Eaexpr2]|(Xy.c(x-y))  In 
E  [expr,  ](<;,) 

(E3)  E I  MULT  expr,  expr2j  (c) 

=  E I  expr,  i  (c,) 

where  c,  =  ixE|[expr2]](X.y.c(xxy)) 
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(E4)  E  ([DIVIDE  expr,  expr2B  (c) 

=  EilexprgiHc,) 
where  c,  =  Xx.E  nexpr,  j  (c2) 

where  c2  =  Xy.(x  =  0  -»  division-error(),  c(y/x))’ 

division-error()  =  "division  by  zero" 

(E5)  EffBDIGITS  bdigit+li(c)  =  c(B  I  bdigit+ 3  (0)) 

(Bl)  B  Gbdigit  bdigit*  ]]  (n)  =  Bllbdigit*j(nx2+bdigit) 

(B2)  B  tfeB  (n)  =  n 

The  semantic  function  A  computes  the  semantics  of  expressions,  using  the  semantic  function  E  to 
compute  the  semantics  of  subexpressions.  The  semantic  function  B  computes  the  semantics  of 
sequences  of  binary  digits.  A  requires  only  one  argument,  the  syntactic  phrase  (representing  an  arbitrary 
expression)  whose  semantics  is  being  computed.  E  requires  two  arguments,  a  syntactic  phrase  that 
represents  an  expression  and  a  continuation  c.  The  continuation  c  is  a  function  that  generally  maps 
integers  to  integers,  but  sometimes  returns  an  error.  If  an  error  (division  by  zero)  occurs,  the  continuation 
mechanism  is  bypassed  and  an  error  string  is  produced  by  the  auxiliary  function  division-error.  B 
takes  two  arguments,  a  (possibly  empty)  list  of  binary  digits  and  a  non-negative  integer,  and  is  used  to 
compute  the  semantics  of  a  sequence  of  binary  digits  Ir.erpreted  as  a  non-negative  binary  number.  Note 
that  in  this  semantics  we  make  no  distinction  between  the  denotation  of  a  binary  digit  and  its  numeric 
value.  Typically,  one  postulates  the  existence  of  a  semantic  function  N  that  maps  denotations  of 
numerals  to  their  numeric  values. 


6.  Common  Lisp  Implementation  of  Semantics  for  L 

A  primary  output  of  DENOTE  is  a  Common  Lisp  implementation  of  the  specified  semantics.  The  contents 
of  the  file  generated  by  DENOTE  for  the  DL  semantics  of  L  is  shown  below.  The  function  named 
binexpr-ai  is  the  entry  point  for  the  implementation  of  the  semantics  of  abstract  syntax  trees  of  L. 

;;;  -*-  Mode:  LISP;  package:  USER;  syntax:  Common-Lisp;  base:  10  -*- 

(defmacro  defrecord  (name  fibody  body) 

’  (def struct  {.name  (:type  list)) 

. , body) ) 

(defrecord  binexpras-expr-bdigits  bdigits  bdigit+) 

(defrecord  binexpras -expr -divide  divide  exprl  expr2) 

(defrecord  binexpras-expr-mult  mult  exprl  expr2) 

(defrecord  binexpras -expr-minus  minus  exprl  expr2) 

(defrecord  binexpraa-axpr-plua  plus  exprl  expr2) 

(defun  binexpr-e-expr  (expr  c) 

(case  (first  exp r) 
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(plua  (binexpr-el  expr  c) ) 

(minus  (binexpr-e2  expr  c) ) 

(mult  (binexpr-e3  expr  c) ) 

(divide  (binexpr-e4  expr  c) ) 

(bdigita  (binexpr-e5  expr  c) ) 

(otherwise  (error  "Illegal  phrase  of  type  ~a:  ~a"  'expr  expr)))) 

(defun  binexpr-al  (expr) 

(binexpr-e-expr  expr  #' (lambda  (x)  x) ) ) 

(defun  binexpr-el  (expr  c) 

(let  ( (exprl  (binexpras-expr-plus-exprl  expr) ) 

(expr2  (binexpras-expr-plus-expr2  expr) ) ) 

(binexpr-e-expr  exprl 
#' (lambda  (x) 

(binexpr-e -expr 

expr2  #' (lambda  (y) 

(binexprtr-apply-cont  o  (list  (+  x  y) )))))))) 

(defun  binexpr-e2  (expr  c) 

(let  ((exprl  (binexpraa -expr -minus -exprl  expr)) 

(expr2  (binexpraa -expr-minus-expr2  expr) ) ) 

(let  ((cl 

#' (lambda  (x) 

(binexpr-e-expr 

expr2  #'  (lambda  (y) 

(binexprtr-apply-cont  c  (list  (-  x  y) ) ) ) ) 

))) 

(binexpr-e-expr  exprl  cl) ) ) ) 

(defun  binexpr-e3  (expr  c) 

(let  ( (exprl  (binexpraa -expr-mult -exprl  expr) ) 

(expr 2  (binexpraa -expr-mult -expr 2  expr) ) ) 

(let  ((cl 

#' (lambda  (x) 

(binexpr-e-expr 
expr2  #' (lambda  (y) 

(binexprtr-apply-cont  c  (list  (*  x  y) ) ) ) ) 

))) 

(binexpr-e-expr  exprl  cl) ) ) ) 

(defun  binexpr-e4  (expr  c) 

(let  ( (exprl  (binexpras-expr-divide-exprl  expr) ) 

(expr 2  (binexpraa -expr-divide-expr2  expr) ) ) 

(let  ( (cl 

#' (lambda  (x) 

(let  ( (c2 

#'  (lambda  (y) 

(if  (equal  x  0) 

(binexpr-division-error) 
(binexprtr-apply-cont 
c  (list  (truncate  (/  y  x) )))))) ) 
(binexpr-e-expr  exprl  c2))))) 

(binexpr-e-expr  expr2  cl)))) 

(defun  binexpr-diviaion-error  () 

"division  by  zero") 
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(defun  binexpr-e5  (expr  c) 

(let  ( (bdigit+  (binexpras-expr-bdigits-bdigit+  expr))) 

(binexprtr-apply-cont  c  (list  (binexpr-bl  bdigit+  0))))) 

(defun  binexpr-bl  (bdigit* 0  n) 

(let  ( (bdigit  (car  bdigit*0) ) 

(bdigit*  (cdr  bdigit*0))) 

(if  bdigit* 

(binexpr-bl  bdigit*  (+  (*  n  2)  bdigit)) 

(binexpr-b2  nil  (+  (*  n  2)  bdigit))))) 

(defun  binexpr-b2  (epsilon  n) 

(declare  (ignore  epsilon) ) 
n) 

(defun  binexprtr-apply-cont  (cont  args) 

(apply  cont  args) ) 

7.  Example  Semantics  for  Sentences  of  L 

Compiling  and  loading  the  Common  Lisp  file  whose  contents  were  shown  in  the  previous  section  gives 
one  access  to  the  function  binexpr-ai,  which  determines  the  semantics  of  sentences  of  L.  Examples 
of  the  semantics  of  abstract  syntax  trees  generated  from  sentences  of  L  are  shown  below, 
command:  (binexpr-al  ' (bdigit s  (1))) 

1 

command:  (binexpr-al  ' (bdigit s  (1  0  1))) 

5 

command:  (binexpr-al  ' (bdigits  (0  0  0))) 

0 

command:  (binexpr-al  '(plus  (bdigits  (101))  (bdigits  (1)))) 

6 

command:  (binexpr-al  '(minus  (bdigits  (1))  (bdigits  (1  0  1)))) 

-4 

command:  (binexpr-al  '{mult  (bdigits  (0))  (bdigits  (1  0  1)))) 

0 

command:  (binexpr-al  '(divide  (bdigits  (1  0  1))  (bdigits  (0)))) 

"division  by  zero" 

command:  (binexpr-al  '(divide  (bdigits  (1))  (bdigits  (1  0  1)))) 


command:  (binaxpr-al  '(divide  (bdigits  (1  1  1))  (bdigita  (1  0  1) ) ) ) 
1 


command:  (binaxpr-al  ' (plus  (minus  (bdigits  (1  1  1))  (bdigits  (1  0  1))) 

(mult  (divide  (bdigits  (111))  (bdigits  (1  0))) 
(bdigits  (1  1))))) 
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command:  (binexpr-al  '(plus  (minus  (bdigits  (1  1  1))  (bdigits  (1  0  1))) 

(mult  (divide  (bdigits  (111))  (bdigits  (0  0))) 
(bdigits  (1  1))))) 


"division  by  zero" 
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